home Today's News Magazine Archives Vendor Guide 2001 Search isdmag.com

Editorial
Today's News
News Archives
On-line Articles
Current Issue
Magazine Archives
Subscribe to ISD


Directories:
Vendor Guide 2001
Advertiser Index
Event Calendar


Resources:
Resources and Seminars
Special Sections


Information:
2001 Media Kit
About isdmag.com
Writers Wanted!
Search isdmag.com
Contact Us









Hardware/Software Co-Simulation Speeds Designs Along

Hardware/software co-simulation can reduce design cycles by as much as 25 percent.

by Bob Williams


There is a tremendous amount of discussion going on concerning hardware/software (HW/SW) co-design, co-verification, and co-simulation, and their impact on the ability to get from specification to gates sooner. The discussion ranges from a view of the entire design process for systems all the way down to single steps in the process, such as developing hardware device drivers. First, a few definitions:

HW/SW co-design is the process of designing hardware and software in a concurrent process where tradeoffs and "what ifs" can be made to determine which functions to put in hardware and which in software. This process would also give designers a chance to see how the system might work at an abstract level with a given partition of hardware and software.

HW/SW co-verification is the process of running software with hardware to determine whether they will function correctly, together. In other words, did the hardware and software teams read the spec the same way? Hopefully, when problems are found, they can be fixed in either hardware or software (not generally the case).

HW/SW co-simulation is the process of running software with hardware where that hardware is described using hardware simulation models (typically VHDL or Verilog models). If HW/SW simulation is fast enough, this process can be used to co-verify and co-design hardware and software.

So why is this becoming such a hot topic? Industry analysts play back numbers such as ASIC gate counts averaging over 50,000 and doubling every two years, lines of code of application code and firmware now costing more to develop than the hardware on the average project, and the design cycle windows shrinking dramatically. In addition, many designs will incorporate core-based MPUıs or large ASIC macro blocks and software will be put into ROM, making a software problem as bad as a bad gate in hardware. This all spells trouble for design and integration teams.

One of the first places to start is at the start of the design process itself, with the design specification. Even before designs are partitioned into hardware and software, the functionality can be checked and verified using system-level techniques such as Electronic System Design Automation (ESDA) tools.

Historically, design process changes are the result of using new point tools for parts of the process and evolving the use of those tools and others which follow. Changes to the design process have traditionally taken longer to evolve than the simple tool evolution. Therefore, discussions of using ESDA tools for graphical design entry and following along the design path with a consistent set of tools which flow out of ESDA may not be practical. In addition, ESDA tools currently do not have a notion of a processor and operating system which control many of the functions which are not in application software or in customized hardware. While these tools help in validating the specification, they currently donıt do much for partitioning. For the moment, ESDA tools can provide code to downstream processes, but this may not necessarily be sufficient for HW/SW co-design. Look to ESDA suppliers to incorporate down stream processor-based HW/SW co-simulation in the near future.

In the meantime there are problems to be solved. Designers are creative enough to see the vision, but pragmatic enough to go with what makes sense now. Thatıs where HW/SW co-simulation and co-verification come in.

Here's an example. In todayıs world, the first time that customized hardware of any real size and complexity is tested from a systems perspective is after it is fabricated and the physical prototypes are built. Software is then downloaded and the fun begins. Ask most firmware developers when they get to test their hardware device drivers (which are critical to the success of the system) and they will probably tell you that the first real test is on the prototype board, when its almost too late to change hardware without a lot of pain.

The more pragmatic engineers are trying every trick in the book to get more systems-level tests run before fabrication. They have tried using fully-functional models of processors and then running hardware simulators against these models, the ASICs descriptions, and application software, only to discover that the simulations run too slowly. They have even recoded the hardware descriptions in "C" in order to make the tests run faster, but at the expense of knowing that these new models do not accurately represent what will ultimately be in the hardware.

Several promising approaches to testing hardware with software before fabrication have appeared in the last year or so, and new ones will appear this year.

One new approach uses HW/SW co-simulation, which can operate at over 10,000 instructions per second--fast enough to do real work. Eagle Design Automation (Beaverton, OR; recently acquired by Viewlogic Systems Inc. of Marlboro, MA) provides a tool called Eaglei that links hardware simulation environments from Cadence, IKOS, Synopsys, Mentor Graphics, and Viewlogic to the software development environment via high-performance processor models. This approach also allows full debug visibility on the hardware and software sides. The system supports interrupts from hardware or software, and allows either the hardware design or the software code to halt the system at breakpoints in order to look at registers, memory, etc.

One pragmatic use of HW/SW co-simulation is to validate the operation of hardware device drivers (usually called firmware) before the real hardware is built. Take the example of an ATM chip. The problem was to develop hardware drivers early so that application software developers could begin to write software code before actual silicon was available.

In this case, the developer was using an Intel i960 jx processor and the VxWorks operating system from Wind River (Alameda, CA). The Verilog description of the ATM chip was simulated using Viewlogic VCS. The customer linked his device driver software to the hardware simulation of the chip (and some peripherals) through an interface to the Wind River operating system simulator, called VxSim. This was all linked together through the Viewlogic Eaglei product. In essence, the firmware developer was able to validate that the driver code worked correctly with the new hardware four months earlier in the design process. The setup took a few days, while the validation runs were accomplished over the course of a month. And yes, many HW/SW problems were discovered, one of which could be rated as critical.

A second example is that of functional verification of ASICs before they are built. In the past, hardware designers had built very large test benches in VHDL to use for the functional verification. But they always ran into problems during integration.

The challenge was verification of nearly a million gates of customized ASICs and a multi-processor based system. The concern was for ASIC re-spins due to system-level problems. A firmware developer used C code diagnostics from a previous generation of the product to generate test vectors for the new hardware.

Hardware and software were then run interactively, with breakpoints set on both sides to pin-point problem areas. The system could be stopped, and both the hardware and software designers could then single-step through code on the same or different workstations. Numerous problems relating to the HW/SW interaction were discovered before fabrication. The setup was relatively easy and the system is in use every day.


Figure 1. Co-simulation at various levels of design.

The end result was that the in-system verification of the hardware was moved forward ten weeks in the cycle. In addition, the software which was written will become part of the product diagnostics. The team also feels that when future changes to the design are requested, it will be easy to go back to the models and verify that the changes will indeed work before they are built.

What does the future hold? HW/SW simulation has a way to go, but the start has been promising. We can look for new approaches to the processor modeling in the form of higher-performance processor models and even in-circuit emulators (ICEs) as processor models. Thatıs right, an ICE, called VSP/TAP, from Applied Microsystems Corp. (Colorado Springs, CO), is now able to access virtual hardware in the form of VHDL or Verilog, and it will be able to talk to both real and virtual hardware in the very near future. We will see the use of software descriptions of hardware components mixed with actual hardware in a single simulation environment, on a single interconnect board, and we already see mixed languages such as VHDL and Verilog in single simulation environments. We will also see an ESDA tool tied into a HW/SW environment.

The early users of HW/SW co-simulation to co-verify hardware and software are reducing their overall design cycles by 15-25 percent. The tools are evolving and are at the stage where almost any processor-based design can use them productively.

Bob Williams is vice president of Marketing for Eagle Design Automation (Beaverton, OR; recently acquired by Viewlogic Systems Inc. of Marlboro, MA).


Sponsor Links

All material on this site Copyright © 2001 CMP Media Inc. All rights reserved.